Everything you need to know about AWS ECS on Fargate before you get started

varad.karpe

2022.02.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

AWS ECS is a container management service provided by AWS. There are 2 launch types in AWS ECS, the first one being AWS ECS on EC2 and AWS ECS on AWS Fargate (To know about AWS ECS in detail, follow this link). In this blog I would like to dive into AWS ECS on AWS Fargate launch type.

In Amazon ECS on AWS Fargate, the management of the cluster and container is delegated to AWS. This way you can run containers and clusters in a serverless manner, without having to worry about provisioning resources.

When you want to launch a container on AWS Fargate, you must provide AWS Fargate with the container, after which Fargate analyses the compute requirements of your container and provisions those resources (CPU, RAM) in a server and then Fargate launches the container in that server in the given region. This happens every time there is a container handover to Fargate.

This is a pay according to usage model in which cost is calculated by the amount of time a container is run and the amount of RAM and CPU it utilises. This is in contrast with the EC2 launch type in which you have to pay for the server regardless of the resources consumed by the container. But this does provide far lesser control over your resources as compared to the EC2 launch type.

At the end of the day, this only leaves the application’s development and management as a point of concern for the dev team.

Fargate is fully integrated into the AWS ecosystem on a container level.

Working with Fargate

Fargate Constructs

First we need to register a task definition, it is a document which defines the application which we are going to run. This includes specifications of the container.
Then we create a cluster, in Fargate mode this is not needed to be provisioned in any way but it does define IAM permissions and acts as a good permission boundary to protect your running application.
Then we can run a task, which is a running instance of the task definition.
If you want to use Fargate to run your containers then you need to select Fargate launch type instead of EC2.
You can register your tasks in a load balancer and place the load balancer in front of your cluster so that requests are forwarded to appropriate containers.
A task definition is stored on a host which hosts all the tasks defined in the document, this also includes a scenario in which your task definition document defines a task which defines multiple containers in which all the containers are run on the same host.
You can import images from Private repositories, public repositories or other 3rd party private repositories.

Compute

1 vCPU = 1024 CPU units.
You can define CPU and Memory requirements at the task level, but also at a container level.
ulimits : The ulimits parameter defines the resource limits of a container of a task. This is only supported in linux containers.
- The nofile resource limit defines the number of files which can be open at the same time in a container.
Since Fargate provisions resources on its own, it can identify the specifications (if present) from the task definition document and provision them accordingly.
Once you define requirements on a task level, you can define container level requirements within a range, which can help Fargate in memory management between containers on the fly.

Networking

We can place a cluster in a private as well as public VPC, giving you the choice to make a cluster publicly accessible. This also provides a lot of security support to the cluster.
We have native integration with VPC, using which we can directly launch tasks in a subnet.
You can attach an ENI to our task through which it can access other AWS services via the ENI’s private IP.
We can allocate a public IP to the Fargate tasks and access public resources.
ENI is also used for the image pull from registries.
It is also used to push logs to CloudWatch.
To achieve these things we need outbound internet access by the security group of the subnet.
If you have an ELB in front of your tasks then remember the target type is not an instance but a specific IP, which is the IP of the ENI.

Storage

In terms of storage there are 2 options

EFS volume based persistent storage. Which can be attached to the containers. This is in the range of 21 to 200 GiB.
Bind mounts for ephemeral storage. You can define mounting points and device names in the task definition, this also lets you add as many volumes as possible.

IAM Permissions

- Cluster Permissions: Users can control which actors can run which kind of tasks on your containers.
- Application Permissions: Allows applications to access AWS services.
  - Create an IAM role which includes all policies which your task needs. Then you can form a trust relationship with this IAM role.
- Housekeeping permissions: These are permissions which are required to keep your application running. Such as ECR image pull, Cloudwatch logs etc.
  - Execution Role: Gives permissions for ECR image pull and to push cloudwatch logs.
  - ECS Service Linked Role: Roles for ENI management. LB target for registration/deregistration.

Logging

In your task definition you must define CloudWatch as your logging service by using the logDriver parameter and set it as awslogs. You can write logs to an external logging service as well as long as you define it in the logging parameter.
You can also define prefixes to your logs on the basis of the containers running in your task which can help you in better understanding of the logs.

I think, in the above sub-sections, I have covered all the essentials you need to know to launch your own AWS ECS cluster on AWS Fargate. You should definitely give it a try as there are multiple steps involved in doing so and I hope the material in this blog helps you in launching a cluster successfully.